こんにちは、ゲームソリューション部のsoraです。
今回は、CEDEC2024のセッションレポートを書いていきます。

セッション概要

https://cedec.cesa.or.jp/2024/session/detail/s6661527e7d3f5/

受講スキル：

• ゲーム開発に関わる方
• データベースでお悩みを抱えている方

得られる知見：

• 分散型データベースの基本的な概念とTiDBの特徴理解
• ゲーム基盤でのTiDB活用ポイント
• DB選定時のワンポイント

セッション内容：

ゲーム業界のインフラエンジニアがこぞって頭を悩ませている課題として、データベースの水平シャーディングを前提としたサイジングがあげられると思います。想定されるDAUなどからシャーディングに落とし込むというプロセスは、言うのは簡単ですが実際の設計は困難を極めます。また、想定と異なればどのタイミングでサービスを止めて、どうスケールするかを考えなければなりません。
パンドランドでは前述の課題解消のため、TiDBと呼ばれるNewSQLデータベースを利用しています。TiDBはこれまでのデータベースとは違い、メンテナンス時間を設けなくてもサービスインしたままエンドユーザーへの影響なくデータベースの拡縮が行えます。本セッションは、パンドランドのリリース後、実際にTiDBをどのように運用しているかその裏側をのぞき見るセッションです。

レポートpart1（TiDBの紹介）

はじめに

本セッションの登壇者様とワンダープラネット社のTiDBを導入したゲームタイトルの紹介です。



以降はTiDBの紹介、ワンダープラネット社でのTiDBの開発・検証・運用の話という流れで進んでいきます。

TiDBの特徴

TiDBの特徴は以下スライドです。
TiDBはMySQL互換のNewSQLデータベースであり、書き込みを含めた水平/垂直スケール・高い可用性・オードシャーディングが特徴です。
ダウンタイムなくスケールアップ・スケールアウトできるのも特徴です。
本セッションのテーマ外ではありますが、列指向でデータを持つことができ、分析用のDBとしても使用することができます。
ゲーム業界ではMySQLが多く、特に頭を悩ませるシャーディングに対してもTiDBで解決できます。

MySQL互換

TiDBはMySQL互換ではありますが、100%の互換性を持っているわけではありません。
ストアドプロシージャ・スパーシャル（空間データ）など一部サポートされていない機能はあるものの、ゲーム業界ではあまり使われていない機能が多いとのことです。
ワンダープラネット社でも互換性で問題になることはなかったとのことです。

TiDBアーキテクチャ

TiDBのアーキテクチャは以下です。
TiDBは1つのクラスタに集約されていて、それぞれのコンポーネントの台数の調整が可能です。

TiKVにて、データの実態は分散してKey-Value形式で保存されつつ、ACIDトランザクションの特徴を持ちます。
シャーディングはプライマリキーのレンジを使って自動で行われています。

TiFlashはオプションで追加可能なコンポーネントで、列指向のデータストアで組み込み型のDWHです。
分析用途で使用されますが、現状ゲーム業界ではあまり使われていないとのことです。
TiFlashは後付け可能であり、TiKVからレプリケーションをとることで使用することができます。

TiDBはアプリからリクエストを受けるコンポーネントで、クエリを解析して行指向のTiKVか列指向のTiFlashのどちらに割り振るかを選定します。

PDは司令塔的な立ち位置で、コンポーネントのやり取りを管理するコンポーネントです。
フルマネージドサービスであるTiDB Cloudでは意識しないコンポーネントとなります。

リージョンと呼ぶデータの区切りで、その区切りに対してLeader・Followerの関係を持ってデータを管理します。
障害が起きてもLeaderの役割を他のFollowerに移すことで、対応が可能です。

レポートpart2（検証・開発・運用）

検証

検証の実施については以下です。
TiDBは複数のコンポーネントがあり、コンポーネント同士で通信が発生するため、レイテンシは若干遅くなります。
どの程度かというと、全ワークロードで一桁msを要求されるとなると厳しいとのことです。

詳細は昨年のCEDEC2023のセッションにて説明されており、当時レポート記事を書きました
https://dev.classmethod.jp/articles/cedec2023-tidb/

開発

ワンダープラネット社における構成は以下です。
ユーザデータ・ログデータは、書き込みが多くTiDBを使用しており、ログデータはS3に移して定期的にTTLで自動削除しているとのことです。
マスターデータは、作成時に物理DDLを多用しTiDBでは物理DDLが遅いため、Amazon Auroraを使用しています。
PingCAP社によると、TiDBにおける物理DDLのアップデートを予定しており、処理速度が改善されるとのことでした。

TiDBの使い分けは以下です。
Dedicatedは、最新バージョンを使用できたり機能制限がなかったり最小構成でもそれなりの費用が掛かることがあるため、ServerlessやSelf-Hostedを活用しているとのことです。

意識したことを3つ挙げています。
オートインクリメントも使おうと思えば使えるが、ホットスポットを回避するためにUIDを採番している。
オートインクリメントはゲーム業界ではあまり使われていないとのことです。
TiDBはダウンタイムなしでスケールアップ・ダウンができますが、コネクション断が発生するため、その対処もされています。
TiDB Cloudではまだ利用できませんが、現在TiProxyというクライアントのリクエストをTiDBに割り振るプロキシが出てきており、それを利用することで対応可能とのことです。

運用

初期構成については以下です。
台数を増やすかスペックを上げるかについて、どこかのTiDBノードがホットスポットにならないために、スペックを上げることで対応しています。
これが結果的には良かったとのことです。

リリースは乗り切ったものの、データ転送料金が想定以上にかかっていたとのことです。
特定のTiKVノード1台の負荷が高く、スケールダウンができず、負荷を分散させる必要がありました。

3つの工夫したことは以下です。
TiDBは分散型DBがゆえにコンポーネント間で通信が発生します。
AZを跨ぐ通信には費用がかかるため、同一AZのFollowerからもデータを読み取るようにすることで料金を抑えることができます。
利用することでレイテンシが悪化することもあるため、設定を調整しつつ導入したとのことです。


TiKVではサロゲートキーがプライマリキーであり、インデックスでデータを取得する場合にインデックスから見たプライマリキーを取得して値を取得する形になります。
インデックスがダメではないですが、TiKV的にはプライマリキーで引いてくるのが一番効率が良く、通信費用も抑えることができるとのことです。

運用で工夫したことのまとめです。
想定とずれていたものが解消したとのことです。

まとめ

以下がまとめです。

感想

昨年と合わせて、TiDB Cloudを実際に検証・開発・運用した話が聞けて勉強になりました。
特にリリースして認識と異なったこと、それに対してどう対処したかの部分を、実際のTiDB Cloudの設定値を交えた部分が聞けて良かったです。
TiDB Cloudは万能なDBではないものの、特に現在MySQLを使っていてシャーディングに悩むゲーム会社様にはとても良いデータベースだと思います。
クラスメソッドでもTiDB Cloudを扱っているため、もし興味があればお問い合わせください。